Add Book to My BookshelfPurchase This Book Online

Chapter 4 - Routing Protocols Used in TCP/IP

Cisco TCP/IP Routing Professional Reference
Chris Lewis
  Copyright © 1999 The McGraw-Hill Companies, Inc.

Interior Gateway Protocols: Distance Vector
The first distance vector protocol was the Routing Information Protocol, (RIP). The discussion that follows on RIP fully explains how a distance vector routing protocol works. We will review the generic distance vector algorithm, followed by discussion of RIP version 1 as the first protocol of this type.
Generic Distance Vector
The distance vector algorithm (sometimes referred to as the Bellman-Ford algorithm for the people who invented it), requires each machine involved in the routing process to keep track of its "distance" from all other possible destinations. What happens is that a router is programmed to construct a table of all possible destinations (in terms of network numbers) and measure the distance to each location. The only information a router has at boot time is what networks are directly attached to it. So how can it find out about all other possible destinations?
Each router is programmed so that it announces all the destinations it knows about, along with the distance to each. Once a router starts hearing all the advertisements from other routers, it can start to list all the possible destinations and calculate the shortest path to these destinations—the one kept in the routing table.
So a distance vector protocol will, on a regular basis, send out an update that contains all the information contained in the machine's routing table. These updates are sent only to neighboring routers on directly connected segments. One of the key differences between distance vector and link state routing is that link state protocols send information to routers on remote segments.
Once these updates get to a router, the router will then use a collection of algorithms and timers to decide what entries should be put into the routing table of the machine that is receiving the updates. Another key aspect of distance vector protocols is that any given machine knows only the next hop in the sequence to deliver the packet to its ultimate destination. In link state protocols, each machine has a complete map of the network it is in (or, more accurately, the routing area it is in—but we will come to that later).
To finish this introduction, let's take a high-level overview of the code behind the distance vector algorithm:
  1. Each router has a unique identification on the internetwork.
  2. Every router will identify a metric to be associated with each link directly connected to itself.
  3. All routers will start advertising directly connected links with a metric of zero.
  4. Every router transmits to neighbors the complete information regarding all destinations and their metric when the router first boots, then periodically, and whenever a router becomes aware of a change.
  5. Each router determines which directly connected neighbor offers the lowest metric to each location.
RIP: The Routing Information Protocol
The first Interior Gateway Protocol (IGP) was the Routing Information Protocol, or "RIP" as it became known. RIP was designed for an environment that had only a relatively small number of machines, and these machines were connected with links that had identical characteristics.
As the first IGP, RIP gained widespread use and was distributed free with BSD Unix as the routed daemon process. As today's heterogeneous networks grow and become more diverse, RIP has been improved upon with more modern, more full-featured distance vector protocols. RIP is still in widespread use and is the only routing protocol that Unix machines universally understand.Okay, before we get into the workings of RIP, let's refresh our memories regarding what a routing table looks like. To display a Cisco router's routing table, do the following:
C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
Gateway of last resort is not set
160.4.0.0 255.255.255.224 is subnetted, 2 subnets
C  160.4.1.32 is directly connected, Ethernet0
R  160.4.1.64 [120/1] via 160.4.1.34, 00:00:12, Ethernet0
In the first column, the router tells us how it learned about the routing table entries. The legend at the top of the display explains what these abbreviations mean. For example, C means that the network is directly connected to the router on the specified interface. S stands for static route and means that the route to this destination network is hard-coded into the router's configuration. R means that the router learned of this destination network via a RIP update.
The rest of the entry in the router's routing table states which interface to use for the specified network, and which router to send the packet to next if the destination network is on another part of the internetwork. In this case, the RIP entry is telling us to use the router with address 160.4.1.34 in order to get to the 160.4.1.64.subnet, and that this router is connected to the Ethernet 0 interface.
Let's look at the rest of this entry in more detail. The [120/1] entry in the RIP line first gives the value of the administrative distance, and then the metric. The administrative distance is a value assigned to routing protocols. RIP has a value of 120, OSPF of 110, IGRP of 100, EIGRP of 90, static of 1, and directly connected of 0.
This administrative distance is used if two routing protocols advertise the same route to the same router. In this case, the router will prefer the route supplied by the routing protocol with the lowest value for administrative distance. The logic behind this is that, because Cisco routers give you the ability to have multiple routing protocols running on the same router, you need some way of deciding which routing protocol is advertising the best route. Clearly the metrics used by different routing protocols are not comparable; RIP only goes up to a metric of 16, while IGRP goes to more than 16 million, so this other measure is used to show preference for the routing protocols in use. EIGRP is most preferred, IGRP next, then OSPF and finally RIP.
The 00:00:12 value is a counter that indicates the amount of time that has passed since the router received an advertisement for this route.
We will now discuss how RIP handles its responsibilities as a routing protocol in more detail.
The Basics of How RIP Works.     Once configured on an internetwork, the operation of RIP and its interaction with the routing table is fairly straightforward. By default, every 30 seconds each RIP-enabled device sends out a RIP update message, comprising routing information from the machine's routing table. This message includes the following:
  Destination address of host or network.
  The IP address of the gateway sending the update.
  A metric that indicates the distance (in terms of hops) to the destination.
It is worth noting that interfaces on a Unix machine or a router can be defined as passive. If that is done, the interface in question does not send out any RIP updates; it merely listens for updates from other machines.
Once a routing device receives an update, it processes the new information, which it compares with that in the existing routing table. If the routing update includes a new destination network, it is added to the routing table. If the router receives a route with a smaller metric to an existing destination, it replaces the existing route. If an entry in the update message has the same destination network and gateway but a different metric, it will use the new metric to update the routing table.
This covers how routers handle a static network using RIP; some additions to the protocol are in place to handle changes in topology, such as a downed link. If the preceding were the only logic coded into a router, it would not recover from a downed link because it remembers only the best route to any given destination. If the gateway, or link to that gateway, should fail, the routing table might never reflect the change.
That's because, so far, the logic defined depended upon a gateway notifying its neighbors of whether its metrics had changed. If the gateway could no longer communicate, it could not notify its neighbors of a change. To handle such situations, RIP employs timers: It sends out messages (every 30 seconds by default), and the protocol assumes that if a gateway or specific route is not heard from within 180 seconds, it no longer is available. Once it determines that a route is unavailable, the router sends a special message that notifies its neighbors of the unavailable route. After 270 seconds, if nothing is heard from the gateways or route, this information is flushed from the router's routing table. These timers are known as the update, invalid, and flush timers, respectively.
To understand fully how a router deals with link or other failures on the internetwork, we need to explore other issues, starting with the count to infinity problem. With a router that uses RIP as its routing protocol, "infinity" turns out to be 16. Clearly, some further explanation is needed here.
RIP's interpretation of infinity as the number 16 relates to the Time To Live (TTL) field in the IP layer header. Each time a packet travels through a router, its TTL field (with initial value of 15) is decreased by one. When the TTL value reaches 0, the packet is discarded and no longer exists in the internetwork. This feature is there to stop a packet caught in a routing loop from being switched back and forth forever between routers. Obviously we want the TTL value to be high enough to allow us to send correctly routed packets through whatever network size we want to implement, but small enough so that packets are not kept in a routing loop for too long. In a RIP-based network, this value is fixed at 15. With IGRP, we can set the value to whatever we like.
Let's see how this situation of a circulating packet can occur, and what features in RIP have been implemented to minimize its occurrence. Referring to Fig. 4-2, consider the situation wherein a PC on network 3 needs to send a message to a PC on network 1.
Figure 4-2: An internetwork in which Split Horizon prevents routing loops
First let's examine what happens with RIP during normal operation. Router A initially will advertise that it knows about networks 1 and 2. Router B will advertise that it knows about networks 2 and 3. (This is similar to the lab we set up in Chap. 3.) After these initial advertisements, both routers know about all three networks. If router B sends an update to router A, stating that it knows how to get to network 1, we can run into some problems. Here's how this can happen.
Suppose the interface on router A goes down and router A cannot contact network 1. If router B is advertising to router A a route to network 1, router A will think that it can get to network 1 by sending a packet to router B. So, if a PC on network 3 wants to send a packet to a PC on network 1 and the interface on router A to network 1 goes down, the packet will get caught in a routing loop. This happens because router B will decide that to get to network 1, it must send the packet to router A. Router A knows that its directly connected interface to network 1 is down and that network 1 cannot be reached that way. Since router A has received an update from router B stating that it knows how to get to network 1, the packet will get sent back to router B and the process starts all over. The only thing that stops this process is the count to infinity.
The Split Horizon algorithm was designed to counter this problem. The effect of the Split Horizon rule is that a router will send out different routing update messages on different interfaces. In effect, a router never sends out information on an interface that it learned from that interface. The logic is that if a router first learns of a network from an adjacent router, that adjacent router must be nearer the network. The effect of this rule in the sample internetwork of Fig. 4-2 is that router B will have learned about network 1 from router A, and therefore, according to Split Horizon, router B will not include network 1 in its routing updates sent to router A.
RIP version 1 implemented Split Horizon with Poison Reverse Update. This formidable-sounding title is, in fact, a small modification to the Split Horizon algorithm described above. All it means is that, instead of not advertising routes to the source, routes are advertised back to the source with a metric of 16, which will make the source router ignore the route. It is perceived that explicitly telling a router to ignore a route is better than not telling it about the route in the first place.
All this means in practice (if the fault condition is in effect) is that a PC will know that it cannot send a message to a PC on network 1 more quickly. This could mean that a user knows he cannot send his message, or this knowledge could kick off some dial-backup facilities to restore service more quickly.
Split Horizon, with or without Poison Reverse, only counters routing loops between adjacent routers. Let's look at Fig. 4-3 and see a situation in which Split Horizon will not save us from a routing loop.
Figure 4-3: An internetwork in which RIP's maximum metric value causes problems
Suppose router C gets a packet destined for network 1; then, in normal operation, the packet is sent to router A for delivery. If the interface on router A to network 1 goes down, router A knows it cannot deliver the packet to network 1 directly and will seek an alternate route. Split Horizon stops router C from telling router A that it knows how to get to network 1, but it will tell router B. After the network 1 interface failure on router A, router B will no longer hear about network 1 from router A, but will hear about it from router C. Therefore, router B will be free to advertise a route to network 1 to router A, stating that it can get to network 1 via router C. This leads to a routing loop between routers A, B, and C, even though Split Horizon is in effect.
Another time when the value 16 has significance in a RIP-based network is when a network has been built that has a path through more than 15 routers from source to destination.
Router D will hear about two ways to get to Network 1, one from router A and one from router C. Router A will advertise network 1 to both C and D with a metric of 1. Router C will increment this metric by 1 (to indicate the packet has traveled through a router) and will readvertise this route to D. Router D will get both of these updates and select router A as the best way to get to network 1, because it has the lowest metric. Now suppose router A had received a routing update from network X, which had a route with a metric of 15. Router A will add 1 to the metric, making it 16. The next router to receive this in an update from A will declare that it is infinity and will eliminate this route from its routing table (if the route existed there in the first place)—or, at the very least, fail to add this route to its routing table.
This means that routers B, C, and D will not be able to reach anything on network X, because RIP will think that network X is too far away. This is annoying, particularly if all of the links and routers are functioning correctly.
Triggered Updates and Hold-Downs.     The larger a network grows, the more difficult it is to get all the routing tables on all the routers updated correctly. The time it takes for all the routing tables to get adjusted by a routing protocol is called the convergence time. To speed up this process, RIP employs triggered updates, which means that whenever a RIP-enabled router learns of a topology change, such as a link becoming unavailable, it will not wait for the next scheduled routing update to be sent out, but will instead send out a triggered update immediately.
Unfortunately, this does not work for all situations. Look at Fig. 4-4 to examine what happens if the link between A and B becomes unavailable. When routers A and B realize that they are no longer connected, they will notify their neighbors of the link failure via a triggered update. All router devices receiving this news will issue triggered updates to their neighbors, indicating the change in topology. Problems occur if, for example, router E is made aware of the change before router D. Router E adjusts its routing table to reflect that the A-to-B link is no longer available; however, if router D has not heard of this change and sends to E a regular update message (assuming that the A-to-B link is still available), E will reinstate the A-to-B link in its routing table.
Figure 4-4: A larger internetwork in which the use of hold-downs is necessary
In this situation, the benefit of using triggered updates has been negated, and we still have to wait for the A-to-B route to expire in all the routing tables in the network. A method for improving the convergence time in this type of situation is the hold-down timer.
The hold-down rule states that when a route is removed, no update to that route will be accepted for a given period of time. In our example, this means router E will ignore the update from router D attempting to reinstate the A-to-B route. This gives the triggered updates time to get to all other routers, ensuring that any new routes are not just reinstating an old link. The downside of this scheme is that the system will not reach convergence in the quickest possible time. However, convergence time with triggered updates and hold-downs is much better than without.
Now that we have explained the operation of RIP, we can go back to the lab and explore the information that the router will give us regarding RIP.
The command show ip route 160.4.1.64 gives some expla-nation of the summarized display given when a Show ip route is executed.
router1#sho ip route 160.4.1.64
Routing entry for 160.4.1.64 255.255.255.224
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 160.4.1.34 on Ethernet0, 00:00:26 ago
Routing Descriptor Blocks:
* 160.4.1.34, from 160.4.1.34, 00:00:26 ago, via Ethernet0
Route metric is 1, traffic share count is 1
The point of interest is that the display tells us the netmask used in determining subnet values, in this case 255.255.255.224. In addition, it explains that the 120 value is the administrative distance and the metric is 1. Further, it explains that the last update for this route was obtained 26 seconds ago from address 160.4.1.34 on Ethernet 0.
The next command, show ip protocols, gives us the timer values, discussed in the preceding section, for this specific RIP system.
router1#sho ip protocols
Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 22 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Redistributing: rip
Routing for Networks:
160.4.0.0
Routing Information Sources:
GatewayDistanceLast Update
160.4.1.341200:00:16
Distance: (default is 120)
Problems with RIP.     In today's large, heterogeneous networks that connect Ethernet segments to serial-line wide area links and dial-up links, the following problems make the use of RIP far from ideal.
  As the network grows, destinations that require a metric of more than 15 become unreachable. This is particularly bad if a network administrator applies a metric of more than 1 to a link, to indicate a slow transmission time.
  The overly simplistic metric generates a suboptimal routing table, resulting in packets being sent over slow (or otherwise costly) links when better paths are available. Other routing protocols use a more complex metric to include the throughput of each link in use.
  RIP-enabled devices will accept RIP updates from any device. This enables a misconfigured device to disrupt an entire network quite easily. Other protocols allow "neighbors" to be defined as the only ones from which to accept routing updates.
  RIP does not carry subnet mask information in updates. It assumes all interfaces on the network have the same mask. Because of this, the network can run out of usable Internet-compatible addresses earlier than is necessary.
  On larger internetworks, convergence time is unacceptably slow (greater than 5 min) for most commercial applications such as database access or financial transactions.
  The Split Horizon with Poison Reverse Update algorithm in RIP only counters routing loops between adjacent routers. Other routing protocols employ more sophisticated mechanisms to counter larger routing loops, thereby allowing the safe use of a zero hold-down value, which speeds up convergence time considerably.
  RIP updates use more bandwidth than other protocols, mainly because the whole routing table is sent in updates.
Even though it may not be the best protocol available, there are still those who have to introduce Cisco routers into a largely Unix-based routing environment, and the only routing protocol that routers can use to exchange information reliably with Unix machines is RIP. With that in mind, let's see what needs to be done to configure RIP on a Cisco router.
The first step is to enable the process on the router, which is achieved as follows:
Router1(config)#router rip
Router1(config-router)network A.B.C.D
The first line defines RIP as a running process, and the second defines the whole network number that will be advertised by RIP on initial startup of the routing process. You need to add entries for all the network numbers that are directly connected. If there may be interfaces on the router that you do not want to send routing updates through, consider Fig. 4-5.
Figure 4-5: The use of passive interfaces on a RIP internetwork
In this figure, the Ethernet 0 port is connected to a local area network. This network may contain routers advertising routes that you do not want to get to the global wide area net. To stop the router sending any of these local routes over the global net, use the passive interface command as shown next. This command stops the router from sending out any updates on the specified interface.
Router1(config-router) #passive interface SO
RIP is a broadcast protocol, so in order for routing updates to reach routers on nonbroadcast networks, you must configure the Cisco IOS to permit this exchange of routing information. This is a fairly rare occurrence. Consider Fig. 4-6.
Figure 4-6: Configuring RIP to send routing updates to a specified router
Suppose you have two sites connected via a public frame relay network and want router 1 to send RIP updates to router 2. With a default configuration for RIP, the frame relay network will not broadcast the RIP update to all connected devices, so we have to tell router 1 to send a directed RIP update message to router 2. This is achieved as follows:
where W.X.Y.Z. is the IP address of router 2.
In summary, the RIP configuration utilizing all these features is shown as follows:
  router rip
  network A.B.C.D
  passive interface serial 0
  neighbor W.X.Y.Z
It is possible to change the value of the update, invalid, and flush timers along with the value of hold-down. I do not recommend you do this for RIP. The only reason to use RIP on a router is if you are exchanging routing information with a Unix machine, and it is likely that the timers and hold-down value for the Unix machine are not easily configurable. If you are concerned enough about the performance of your routing protocol to adjust the timers, you should not be using RIP, but rather something such as IGRP, and use redistribution (discussed later in this chapter) to exchange route information with Unix machines.
RIP performed its job well, given what it was designed for, but its time as the only routing protocol to run on a large and diverse network is over. Let's look at how Cisco improved things with the Interior Gateway Routing Protocol, IGRP.
IGRP: Interior Gateway Routing Protocol
Cisco's stated goals for IGRP include the following:
  Stable, optimal routing for large internetworks, with no routing loops occurring.
  Fast response to changes in network topology.
  Ability to handle multiple "types of service" (though not currently implemented).
  Low overhead in terms of bandwidth and router processor utilization.
  Ability to split traffic among several parallel routes when they are of roughly equal desirability.
The key differences between RIP and IGRP are in the metric, poisoning algorithm, and use of default gateway. IGRP's Split Horizon, triggered updates, and hold-downs are implemented in a fashion similar to RIP.
IGRP Metrics.     IGRP computes a vector of metrics that is used to characterize paths. This metric value can exceed 16 million, which allows a great deal of flexibility when mathematically describing link characteristics. This composite metric (as defined by Cisco) is calculated as follows:
[(K1/B) + (K2xD)]xR
where  
K1, K2 = constants
B =
unloaded path bandwidth x (1–channel occupancy). This is for the narrowest bandwidth segment of the path.
D =
Topological delay
R =
reliability
Two additional data elements are passed in routing updates: hop count and Maximum Transmission Unit, although neither currently are used in the calculation.
K1 and K2 indicate the weight to be assigned to bandwidth and delay, and are defined by the type of service requested for a packet. In reality, the metric calculation is much simpler than this equation would suggest. If two routers are connected via their Serial 0 ports, the default bandwidth assumed for the metric calculation is 1.544 Mbps (T-1 speed). For a T-1, IGRP assigns a composite delay of 21,000 ms. By default K1 = 10,000,000; K2 = 100,000; and R = 1. This gives a metric of 8576 for every serial port connection on a network, regardless of the actual line capacity in place. This metric value can be viewed by using the show ip route A.B.C.D command, in which A.B.C.D is the IP address of a device on the other side of the serial port link. An example is shown as follows:
router1#sho ip rout 160.4.1.64
Routing entry for 160.4.1.64 255.255.255.224
Known via "igrp 9", distance 100, metric 8576
Redistributing via igrp 9
Last update from 160.4.1.34 on Ethernet0, 00:00:33 ago
Routing Descriptor Blocks:
* 160.4.1.34, from 160.4.1.34, 00:00:33 ago, via Ethernet0
Route metric is 8576, traffic share count is 1
Total delay is 21000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0
Metric values can be customized using the bandwidth interface command for each serial port, to factor in actual bandwidth available for each link for metric calculations. This is a good idea.
As stated, the Cisco IOS, unless it is configured otherwise, will decide that each serial link is using a T-1 for the purposes of metric calculation.
This can be verified by issuing the following command on router A (see Fig. 4-7).
Figure 4-7: Internetwork in which interface bandwidth commands are necessary
RouterA>show interface serial 1
Serial1 is up, line protocol is up
Hardware is HD64570
Internet address is 160.4.1.65 255.255.255.224
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
The first four lines of command output are shown. As you can see, the bandwidth assumed is that of a T-1, even though a 64 kbps line is in use. It would have been nice if this bandwidth value had used what was actually there by default; because the router is getting the clock signal from the line CSU/DSU, it does have the information to do so—but the connection in the Cisco IOS is not made.
Why is this important? As previously stated, IGRP will split traffic between paths that it thinks are of equal value in terms of the composite metric. If no adjustments are manually made to the router configuration to change the value of bandwidth used for the 64 kbps links in the metric calculation, router A will calculate the metric from network 1 to network 2 as 17152 (8576 + 8576) for both the route through router D and the route through router B. Transferring a file from a machine on network 1 to a machine on network 2 will mean that the traffic is split equally between these two paths. As you can see, the available bandwidth of these two paths is actually very different, which will lead to a suboptimal rate of file transfer.
The way to fix this is to assign appropriate bandwidth values to each link. This is achieved as follows:
RouterA(config)#interface serial 1
RouterA(config-int)#bandwidth 64000
The same should be done for the Serial 1 interface on router B. The result of this is that the route from network 1 to network 2 will have a far lower metric through router D than through router B. As the routes no longer have equal metrics, for a file transfer from network 1 to network 2, the path through router D will carry all the traffic.
In the Cisco IOS, the concept of variance can be used to define unequal-cost load balancing. This means that if up to four paths are roughly equal, traffic will be split among them, in inverse proportion to their metric value. These alternative path metrics must be within a specified variance multiplier of the best metric. The variance value multiplied by the best metric defines the upper value of the metric of the links that will be considered for unequal-cost load balancing. In Fig. 4-8, we see an internetwork that, with appropriate settings of variance, will allow traffic between network 1 and network 2 to be split between routes through router B and D, in proportion to the bandwidth available.
Figure 4-8: Internetwork in which the use of variance is recommended
In this instance it is desirable to have traffic between network 1 and 2 split between the two paths. If the variance is set to a value greater than 1, traffic may be split over paths of unequal metric. A value of 1 is the default and means that traffic will only be sent over the best path, or split between equal paths. If the variance is set to 1.5, it means that any path with a metric up to 1.5 times the metric of the best path will be added to the routing table and used when sending traffic.
The variance multiplier is set as follows:
RouterA(config-router)#variance 1.5
Caution must be taken with network design due to IGRP's ability to use load balancing. As long as either the Data Link or Transport layer protocol can handle receiving out-of-sequence packets, everything is fine. If one is using frame relay, for example, to transport UDP packets in an internetwork with multiple routes between networks, however, the IGRP feature will cause problems, because neither frame relay nor UDP guarantee correct sequencing of packets. In this instance, using TCP as the transport protocol, or swapping to LAPB for the link-level protocol, will resolve the problem.
IGRP Route Poisoning.     The poisoning algorithm used in IGRP can counter larger routing loops than can the Split Horizon with Poison Reverse used by RIP. RIP's poisoning algorithm only counters routing loops between adjacent routers. IGRP will poison routes in which metric increases by a factor of 10 percent or more after an update. This is based on the logic that routing loops generate continually increasing metrics. Using this type of poisoning rule will mean that certain valid routes will be erroneously deleted from routing tables. If routes are valid, however, they will be reinstated by the next regular update message. The key advantage to this type of poisoning is that it safely allows a zero hold-down value, which speeds up network convergence time considerably.
IGRP Default Gateway.     For routers, the network number 0.0.0.0 has special significance to identify a specified router as the default gateway. A default gateway is used by the router when it has to forward a packet destined for a network that is not explicitly listed in the routing table. Consider this routing table from a Unix machine:
Gateway FlagsRefCntUseInterface
123.0.0.0134.4.4.4UG405000le0
134.4.0.0134.4.4.1UG507000le0
0.0.0.0 134.4.4.5UG102000le0
This router knows about two real networks (the 123.0.0.0 and 134.4.0.0), as well as the default network of 0.0.0.0. If the router has to forward a packet to anything other than the two real networks about which it knows, it will send the packet to the router with IP address 134.4.4.5, hoping that it will know how to get the packet to its final destination. This function is useful if you want to reduce the amount of network numbers a Unix machine must know about, but still have it participate in routing decisions. Consider Fig. 4-9, which shows an internetwork that would generate the routing table shown above.
Figure 4-9: Internetwork with one router operating as the default
In this internetwork, the Unix machine is effectively delegating all the WAN routing decisions to the WAN router, which is acting as a boundary router to the global network. Routing protocols will circulate information about this default route in routing updates as if it were a real network. This can cause problems if this one gateway, defined as the default, becomes unavailable. With RIP, 0.0.0.0 is the only way to define a default gateway.
IGRP takes a different approach that allows real networks to be flagged as candidates for being a default. This is achieved by turning on a bit associated with those networks, marking the networks as being a candidate. Periodically IGRP scans the routers offering a path to this flagged network, selects the path with the lowest metric, and uses that as the default (Fig. 4-10).
Figure 4-10: Internetwork using Cisco's default-network feature
In this figure, two routers, router 1 and router 2, both have a connection to the global Internet, which in this case is accessed via the 130.6.0.0 class B network. In this internetwork, the network number that is used to access the Internet will be flagged as the default in both of the routers that are connected to the Internet. This is done by entering the following global configuration command into both router 1 and router 2:
Router(config)#ip default-network 130.6.0.0
In this case, an asterisk will appear in the routing table of all routers against the entry for the 130.6.0.0 network, indicating that this is the default network. All routers should choose router 1 as the way to access this network number.
Now suppose host 1 has router 5 configured as its default gateway. This means that it will send all packets not destined for the local network to router 5. Router 5 will have selected router 1 as the way to get to the default network. Thus, if host 1 has to send a packet to 202.14.5.3, which is on the Internet, it will send the packets to router 5. Router 5 will realize it does not have a route to the 202.14.5.0 network and will send the packet to router 1, which it already has chosen as its route to the default network. As long as router 1 has an entry to the 202.14.5.0 network, the packet will be delivered.
The concept is that if a default network is identified, and a router does not have a route to a given network, it will send the packet to the default network, assuming that some router on the way to the default network will have a routing table entry for the ultimate destination.
This keeps local routers, such as router 5 in Fig. 4-10, from having to maintain very large routing tables.
One command that could be confusing is the ip default-gateway command. You might think that it defines a default gateway for the routing table to use during normal operation. It does not. This command is there for upgrading routers remotely; we will revisit it in Chap. 7.
Before we move on, let's just see the default-network command operate in the lab we used in Chap. 3. If we configure the routers as previously shown in Chap. 3 and Fig. 3.5, and connect the Ethernet 0 port on router 3 to the hub, we will bring the Ethernet 0 port on router 3 into the up state, which means it can participate in the routing processes. Router 1 does not have a routing process configured, but is configured with a static route to 150.1.0.0 via 120.1.1.2. Router 2 is running IGRP with network subcommands for 120.0.0.0 and 150.1.0.0. Router 3 has a router IGRP process with network subcommands for 150.1.0.0 and 193.1.1.0. Finally, router 1 is configured to have the following entry in its configuration:
Router1(config)#ip default-network 150.1.0.0
We want router 1 to be able to ping the 193.1.1.1 interface on router 3 by sending a ping packet to router 2, which is marked as the router to go to for the default network 150.1.0.0.
This will cause router 1 to mark with an asterisk the entry for the 150.1.0.0 network in its routing table, denoting that this is a candidate for default.
The routing tables for routers 1, 2, and 3 now look like this:
Router1>show ip route
C120.0.0.0 is directly connected, Ethernet 0
S*150.1.0.0 [1/0] via 120.1.1.2
Router2>show ip route
C120.0.0.0 is directly connected, Ethernet 0
C150.1.0.0 is directly connected, Serial 0
I193.1.1.0 [10018576] via 150.1.1.2, 00:00:40, Serial 0
Router3>show ip route
I120.0.0.0 [10018576] via 150.1.1.1, 00:00:52, Serial 0
C150.1.0.0 is directly connected, Serial 0
C193.1.1.0 is directly connected, Ethernet 0
If we try to ping 193.1.1.1 from router 1, the following happens:
  1. Router 1 sees that the 193.1.1.0 network is not listed in its routing table. It then sees that network 150.1.0.0 is flagged as default, so the router sends the packet destined for 193.1.1.1 to the router that knows the way to the default network, that being router 2.
  2. Router 2, which knows about network 193.1.1.0, receives the packet, so the packet is forwarded on to router 3.
  3. Router 3 receives the packet and delivers it to 193.1.1.1.
  4. To reply to 120.1.1.1, router 3 has an entry in its routing table to pass the packet to router 2, which passes the reply packet back to router 1.
This feature is useful because it minimizes the number of entries needed in the routing table of router 1.
Configuring IGRP.     The following is a typical configuration to define IGRP as a routing protocol on a Cisco router:
router igrp 12
timers basic 15 45 0 60
network 162.4.0.0
network 193.1.1.0
no metric holddown
metric maximum-hop 50
The first line defines the routing protocol to be IGRP, for the autonomous system 12. An autonomous system is a network that is administered by one person or one group. For most organizations, every routing device will have the same autonomous system number. IGRP will not exchange updates with routers from different autonomous system numbers.
The second line shortens the default value of IGRP timers. The values indicated here use: 15 seconds for the basic time constant, for when regular update messages are broadcast; 45 seconds for route expiry, if no updates for that route are received; 0 seconds for hold-down, and 60 seconds for flushing the route from the routing table.
The third and fourth lines identify the networks directly attached to the routing device being configured.
The fifth line disables hold-downs, meaning that after the route for a given network has been removed, a new route for that destination network will be accepted immediately.
The sixth line removes packets if they have passed through 50 routers. This number should be large enough to allow all valid routes within your network, but as low as possible to speed up the removal of any packets caught in a routing loop.
When used with appropriate entries in the interface configurations to identify the correct bandwidth value to use in metric calculations, the foregoing configuration should serve most internetworks well. This configuration for IGRP timers is known as Fast IGRP, as it speeds up network convergence time considerably, compared to standard IGRP timers.
As with RIP, a neighbor can be defined if routing updates need to be sent to a router that is only reachable over a network that does not support a broadcast protocol.
IGRP will service most networks very well. There are only a few instances when IGRP causes problems on an internetwork. These problems are endemic to all distance vector protocols. If the following scenario fits the description of your internetwork, you should consider reviewing the use of a link state protocol, or the hybrid EIGRP.
Suppose that your organization is using an InterNIC-assigned class B network number, split into several hundred subnets allocated to geographically dispersed sites. Each site has a dial backup link to a central location. If the link to a site goes down and the site equipment dials in to the central location, all routers on the network need to know that this has happened, and also the new way to reach this site. Triggered updates get sent around the whole network and all routing tables are adjusted.
A distance vector protocol will send out periodically all the information from its routing table (with some minor adjustments for the Split Horizon rule). If there are enough subnets in the routing table, these periodic updates can swamp a dial-up link. Link state and hybrid protocols send updates that contain only the information relevant to the change that has occurred on the internetwork.
The question of distance vector versus link state is not an easy one to answer. We shall revisit how to make this choice at the end of the chapter.

 


 
Books24x7.com, Inc © 2000 –  Feedback